IBIS Macromodel Task Group Meeting date: 01 October 2013 Members (asterisk for those attending): Agilent: * Fangyi Rao Radek Biernacki Altera: David Banas Julia Liu Hazlina Ramly Andrew Joy Consulting: Andy Joy ANSYS: Samuel Mertens * Dan Dvorscak * Curtis Clark Steve Pytel Luis Armenta Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Feras Al-Hawari * Brad Brim Kumar Keshavan Ken Willis Cavium Networks: Johann Nittmann Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: Greg Edlund Intel: * Michael Mirmak Maxim Integrated Products: Mahbubul Bari Hassan Rafat Ron Olisar Mentor Graphics: * John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: * Randy Wolff * Justin Butterfield NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: Eckhard Lenski QLogic Corp. James Zhou SiSoft: * Walter Katz * Todd Westerhoff Doug Burns Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla Ray Anderson The meeting was led by Arpad Muranyi ------------------------------------------------------------------------ Opens: - Need a volunteer to take minutes, Curtis to take the minutes. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Walter - send last week's presentation to Mike LaBonte for posting - done. - Arpad - duplicate Walter's examples using BIRD 125 - done (discuss today). ------------- New Discussion: New proposed topics/questions: - Arpad - Michael Mirmak and Fangyi indicated they have new topics/questions: - Fangyi - I have two questions related to AMI_GetWave(). - What is the expected size of the clock_times array? - Model makers need to know this to avoid writing out of bounds. - How can a model return a message to the EDA tool after AMI_GetWave()? - There is no msg parameter like there is for AMI_Init(). - Arpad - I'd like to set aside a few minutes for Fangyi's questions. - Please don't drag out the discussion. If it will be long, I may move on. - Walter - I understand Fangyi's concerns. - Second question - I think there's only one consistent way to do it. - New Reserved AMI parameter called "message out" (or similar). - Optional and Usage Out. - Standardize a method for returning messages from AMI_GetWave(). - Could have reserved string indicators ("Error", etc.) - Could perhaps allow different return values from AMI_GetWave(). - Arpad - The emphasis would be on "Reserved" parameter. - Walter - We could do a BIRD for this. - Fangyi - Can the model maker use the msg pointer allocated for AMI_Init()? - AMI_GetWave() could update AMI_Init()'s msg string. - Walter - I'm not sure off the top of my head, would have to think about it. - Fangyi - My impression is that msg was intended to be used that way. - Is that the intention of the spec? - Arpad - I don't have it on top of my head either. - I vaguely remember some of the discussions. - Todd - I remember it as being for AMI_Init() only. - Walter - To your first question, I vaguely remember discussions. - Related to "EDA tool allocates the array and the model fills it up." - EDA tool knows how much time in the last AMI_GetWave() call and the bit rate. - We should say something like: - "EDA tool allocates the clock_times array size equal to the elapsed time of the AMI_GetWave() call [its block of data] divided by the bit time plus some fudge factor." - It would be dumb for the EDA tool to allocate less than that, but... - The standard should be enhanced to say "allocate at least this much" plus. - Should be a BIRD clarifying it for model makers. - Could force the EDA tool to pass in an array of zeros with -1 as last entry. - Arpad - We don't need a solution now, we can work on it. - The spec is missing this information right now. - Fangyi - Right. - Arpad - Can we move on now? - Fangyi - Do we agree that both need to be enhanced? - Arpad - Yes, it would be useful to mention it in the spec. We can work on it. - Fangyi - yes. - Arpad - Michael [Mirmak], can you specify your new question? - Michael - May be tricky to summarize the question and keep the discussion short. - Recently seen a significant split in where models put their analog info. - Pre 6.0 models. - Some models: - All analog information in the traditional IBIS format. - All algorithmic information in AMI files. - Now, however, some other models: - Traditional IBIS model is "worse than a dummy" (virtually empty). - It's stated that all behavior is inside the .dll and .ami file. - Specific tools are referred to... - I think this [the latter] can't possibly be portable. - Can EDA Vendors support both? - Walter - Both SiSoft and ADS support Touchstone files, Tx_r, Rx_r, etc. - For supporting on-die s-parameter models, and contained in the .ami file. - These models could readily be converted to 6.0 [External Models] now. - It would be nice to have a 6.0 parser to support that. - However, some models now where analog info is claimed to be in the .dll - I think that is fundamentally flawed. - Return loss can't be handled in the .dll. - I think the ADS and SiSoft touchstone support in .ami is valid. - I think no one is logically supporting analog info in the .dll. - Todd - More importantly, you can't do it! - Arpad - Unless you pass the channel into the .dll... - ... and the .dll is an analog simulator. - Walter - You can't. - Todd - You can do it, but it's not AMI. - Arpad - Yes. - Does that answer your question, Michael? - Michael - Yes, I think so. I think these models are a problem. Next Topic: - Arpad - [presenting his AR for this week - examples in BIRD 125 syntax] - Cyan section - IBIS file. - Yellow section - subckt. using IBIS-ISS. - Red section - how ISS circuit would be instantiated and connected: - language, parameters, port names matched to [Pin Numbers] keyword. - Walter - Could I ask a question when you're done? - Arpad - Yes. - Walter - Quick question, can parameters have corners? - Arpad - If parameters come from .ami or params files: - They could be a reference to a corner type. - Walter - Bottom line, [Define Package Model] doesn't support typ/min/max. - Arpad - It could be done simply. I didn't want to complicate the example. - Walter - I mention an annoyance with IBIS. - [Pin Names] are really pin numbers, and now [Pin Numbers] are names. - Arpad - Yes, it goes back to the original Package Model stuff. - Arpad - [continuing] - SiSoft slide 8. Subcircuit with parameters framis, length reused. - In 125, subckt is a blank holder for parameter passing. - Walter - Same comment, no corner values for parameters. - Arpad - I did consider this but didn't want to complicate BIRD 125 now. - It could be done with a reference. - Bob - Package corners would track [Model] corners. - Is that the way it should work? - Walter - No, [Model] is talking Silicon, Package is talking about package. - Independent corners. - Bob - It could refer to .ami file and use Corner or List there. - Walter - Do we have [Pin Numbers] section with die ports? - Arpad - It's not new, only the second column is new. - Walter - [Package Circuit] is all new? - Arpad - Yes. - Walter - So it's all new, except for some basic boiler plate stuff. - Bob - Sometimes people think building on old stuff is easier. - It can be bad. - Makes it harder to throw away old garbage. - Arpad - I had a brand new idea no one has seen yet. - It applies to the "sliding package models" concept. - I realized there's a better way to solve this issue. - Threw out the old way and the new idea is: - Connection is basically made through the name of the [Model]. - New keyword instead of [Pin Numbers] is [Model Names]. - Indicating that the first column contains the [Model] name. - From the IBIS file's [Pin] keyword (third column - model name). - We need dummy names for that circuit (pin names, pad names). - Are we supposed to make the model maker create these node names? - Do we let the tool generate names for these locations? - This wasn't quite clear to me in Walter's examples either. - We need to know how the tool creates the names for the connections. - Walter - No, in mine I have terminals. - The info I have for differential terminals that are [Model] names includes polarity (inverting or non-inverting). - Arpad - You still don't name the pin or pad. - Walter - In the DQ example it's the DQ pin or the DQ pad. - Arpad - The point is we have pin and pad names and connect the subcircuit. - s10p for DQ0 and Vdd. - Notice the s10 doesn't get everything connected. - Only the two are connected. The rest are dangling. - I've created names for the NC's for the others. - Walter - In what I'm doing we can tie directly to the s10p. - If you want to connect to an sNp, there is no need for a wrapper. - No wrapper subcircuits (yellow section). - They are an unnecessary burden on using touchstone files. - Arpad - In these examples I was making use of IBIS-ISS. - Ambrish - There is precedent in BIRD 160. - Arpad - [concludes examples] - Walter - What you have in the [Define Package Model] is: - pin numbers, model names, package subcircuits. - Each of my examples is independent. - If you tried to take all the examples and put them in one "package file" and the let the user choose: - I think it will be hard for you. - You're customizing your pin and package model names for each one. - I think your justification of BIRD 125 is reuse. - But all you're reusing is a few boiler plate items like [Manufacturer]. - I think it's complicated. - EDA tools will need new parsers for all this, regardless of our choice. - Reuse isn't an argument. This group should decide on a path now. - Does Ambrish still want to pursue BIRD 145 for on-die interconnect? - Or does he want to use an extension of Arpad's or mine? - Arpad - Thanks Walter. I'd like to hear from others too. - I agree we will have to make a decision soon. - We need to choose or implement both in the spec. - Brad - We've had a lot of discussion. - Both Walter and Arpad are talking about a decision on implementation. - I approach this differently. I support a lot of post-layout verification. - No good way for me to bring in a whole package model (s10p or s50p). - Here we're talking about bringing in approximations or channel models. - My customers can't use them. - To one extent I like Walter's EMD. - On the other hand I like Arpad's simple way to connect package models. - I care about standardizing a package mode I can extract today, but my customers can't use. - John - It's telling that we don't have it figured out in either proposal. - Brad - That's what I call part of the automating. - John - A bunch of Monte-Carlo runs. - Michael - Which features do you need the least? - I'm sensing that aggressor definitions are less important. - More important is just getting in a full package? - Brad - Do we standardize the inputs to EDA tools? - I'm sitting here with an s-parameter model and no way to hook it in. - Arpad - Is this slide [today's presentation] what you're looking for? - Brad - Yes, except I want multiple Vdd. - Walter - There are many issues with the way people define package models. - You need a complete package or a full quadrant. - But there are other needs too. - There are other ways other vendors deliver package models. - I think we can't ignore the other vendors' approaches. - Brad - I call a package model, "Here's a model of my package." - Versus a channel model which is DQ0, etc. - But it's a channel model that is assembled as a package model. - I have a 50 port package model. We're trying to figure out how to use it. - Walter - I understand. - There are some package models. - There are some who need channel models that are valid for that package. - Brad - That's an approximation and the EDA tool has to assemble it. - Arpad - I want to try to aim the discussion so that we can progress. - Do we have to make a decision? Can we consider both? - Walter - Is there anything you're proposing that mine can't do? - Arpad - But I've been demonstrating that mine can do everything yours can. - So that approach doesn't help. - Arpad - It seems like we could implement 125/145 in less time than EMD. - Seems like EMD might be longer term. - Walter - EMD is done. It just needs some word-smithing. - EMD for modules is straightforward, would just need the approval stage. - I think implementing EMD is a lot simpler. - No corners in yours. - Arpad - We can do it with a reference. - Walter - More gobbledygook now for corners. - Haven't even looked at 145, which wants to use ISS for on-die modeling. - Even more complicated. - Arpad - BIRD 160, ISS is in 6.0. - Walter - For buffer models. - Arpad - [External Model] and [External Circuit] supported. - Walter - Are there any IC vendor models that use [External Circuit]? - Are anyone else's customers using them? - There's something fundamentally wrong with them. - Arpad - [External Circuit] was limited by the available language options. - Now we have IBIS-ISS allowed. - Walter - BIRD 145? - Michael - Is it possible to get a side-by-side bullet point listing. - Need to see a simple listing of the differences. - That would get you a quick answer. - Arpad - Walter tried something like that a few meetings ago. - Michael - It would be helpful. Get a decision and move on... - Arpad - Walter, can you and I try a few bullet points together? - Walter - Sure, but I'm going out of town. - Limited bandwidth before the next meeting. - Arpad - I'll try it. - Walter - Send me an email and I'll try to get to it. - Arpad - Okay, thanks everyone. I think this is a good time to stop. - See you all next week. ------------- Next meeting: 8 October 2013 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives